The present invention relates generally to selection of options or desired features for computer systems employing user interfaces having menus, e.g., graphically-oriented user interfaces (GUI). More specifically, the present invention relates to a system and method for managing menu/option choices displayed on a monitor of a computer employing such a user interface.
Some applications executable on the computer system have a large number of features, options, and tools that a user is able to customize and select. One common mechanism for selecting features, options and tools is by way of a "menu" of choices presented by the particular application or operating system. The menu is often a horizontal row of word choices identifying general categories of options. A user is able to select one of the menu choices through use of an input device, e.g. mouse or other relative-pointing device, attached to the computer system. In a well known fashion, the mouse controls a position of a cursor displayed on the screen.
Selecting the menu item, such as by activating a button associated with the mouse when the cursor overlies the menu choice will select that menu item. If the item identifies a category, a "drop-down" menu of choices related to that category will be presented to the user. The user then is able to select an item or choice to further select an option tool or feature, or activate a "fly-out" menu of additional menu choices, or to select a dialog box for making a particular choice.
The menu structure works well to hierarchically organize the various features available to a user. There are, however, a number of drawbacks to the conventional menu system. One difficulty is that the conventional menu system is designed to allow only a single selection before reverting back to the initial state. For complex menus, as is typical for applications having a large number of menu options, it becomes necessary to navigate a number of submenus each time a feature is desired. In some instances, it is necessary to periodically toggle a selection, or to otherwise make many selections from the menu. These actions can reduce the usefulness of the program as the user may spend significant time just using the menus to make the desired selections.
In an effort to improve the performance of these menus, various refinements have been made to the conventional menuing systems. One such refinement relates to providing shortcut keys to automatically and directly make a selection from a menu choice without navigating the menu structure to the particular desired menu option. This system moves away from the user interface paradigm as it requires memorization of key combinations, and requires use of a keyboard. To overcome this difficulty, a system was developed for directly selecting desired features through use of the mouse. These systems go by different names, but are generally referred to as iconbars or palettes. Selection of an icon or a palette image would directly select a feature desired by the user. These systems tend to be somewhat inefficient in space requirements, as they provide only a relatively few number of options. Customization of the palette or iconbar can sometimes be difficult.
Another innovation relates to "tear off" menus that provide a user with the ability to lock a particular menu or submenu open. Thereafter, selections can be made continuously from the locked menu. These systems tend to clutter up a screen area because they cannot be customized. It may be that several sets of tear off menus are needed to provide the access to a commonly used subset of functions. There is no quick and easy way to allow a user to configure a tear-off menu to include only desired features. Tear off menus must be used as the application presents them, with the function groupings preconfigured.
FIGS. 7-10 identify some of the menuing systems of conventional applications available in a graphical user interface generated under the Microsoft WINDOWS environment. FIG. 7 is an illustration of a window 500 having a menu list 502. Menu list 502 is arranged horizontally across the top of window 500 and is made up of a plurality of menu options.
FIG. 8 is an illustration of window 500, and a conventional menuing system, when a menu option is activated. As illustrated in FIG. 8, selection of the "File" menu option from menu list 502 causes a "drop-down" menu 504 to overlie part of window 500. The menu option "File" is inverted to indicate it has been selected. Note that drop-down menu 504 presents additional choices as menu options.
Some of the options, such as the "Empty Clipboard", "Exit Task Manager", and "Exit Windows" options, will initiate some action. Other menu options, such as the "Run . . ." and the "Edit Run Contents . . ." options cause a dialog box to be displayed to allow the user to take some desired action, or to select some feature. The ellipsis following the menu option identifies the option as one that will display a user dialog box. The "Preferences" menu option will cause a "fly-out" menu to be displayed, from which other menu options are available. The small triangle to the right of the menu option identifies the menu option as producing a fly-out menu.
FIG. 9 is an illustration of a dialog box 506 produced after the user selects the "Run" option from the drop-down menu 504 of FIG. 8. Dialog 506 allows the user to, in this case, to select an application to be executed by the processor 108.
FIG. 10 is an illustration of a fly-out menu 508 generated after the "Preferences" menu option from drop-down menu 504 is activated. Again, the menu option "Preferences" is highlighted and an additional series of menu options are displayed to the user. After selecting a menu option from this menuing system, the menu returns to the display in FIG. 7, unless the selected menu option is inconsistent with redisplaying window 500, such as when the system exits or a new application is launched.
As illustrated, navigation of this type of menu system allows a user to select a particular menu option in a multilevel menu structure. Unfortunately, only one selection may be made at a time, before returning to window 500 as in FIG. 7. Thus, for an application requiring frequent access to the menu options, such a menu system is inefficient.